Subject: Source TCP Port Resolution Proposal

From: Frank Bordonaro <[email-masked]>
Date: Tue, 7 Nov 95 17:50:23 EST

Source TCP Port Proposal
                    ------------------------

At the DLSw Version 1 Interoperability Tests some vendors
were opening TCP connections to destination port 2065 from
a random source port instead of port 1067. 
This raised two questions. Is this a violation of the RFC1795? 
If not, should we allow this?

Violation of the RFC1795?
-------------------------

The text in section 3.0 Transport Connection of RFC1795 
states :

The default parameters associated with the TCP connections between  Data
Link Switches are as follows:

Socket Family     AF_INET        (Internet protocols)
Socket Type       SOCK_STREAM    (stream socket)
Read Port Number  2065
Write Port Number 2067

It can be debated if "default" is strong enough wording to enforce 
use of port 2067 as the source port. I believe there were Connect
RIG attendees that felt both ways.

This proposal takes the position that "default" is not strong
enough wording to enforce 2067 as the source port.

Should we allow this?
---------------------

We should accept connections into destination port 2065 from
any source port for several reasons :

1. This is the model used by the vast majority of TCP users
   such as FTP and Telnet. The source port is always random.
   This allows multiple TCP connections for the same service
   between two hosts. This is a useful attribute to have for
   DLSw for future features.

2. Some vendors expressed concern because it was a major
   problem for their implementations to nail down the source port
   to 2067. Some of these vendors use TCP stacks that do not
   allow the TCP user to specify the source port. Making a source
   port of 2067 a requirement would force a TCP stack change.

3. This proposal asserts that to allow incoming connections from
   a random source port only requires that DLSw boxes do not
   check the source port. This is likely a few line change for
   any vendors that enforce this today. 

   Another way to look at this is that instead of four parameters
   (src/dest ip/port) uniquely describing a TCP connection, now only
   three parameters do. Implementation will still be able to detect 
   duplicate TCP connections between peers.

Regards,
Frank Bordonaro
cisco Systems, Inc.